La révolution LLM SAP Testing

Le test comprend toute une série d'activités. Les tests unitaires (développeurs) et les tests d'acceptation par les utilisateurs (utilisateurs clés) se situent aux deux extrémités d'un projet SAP. Entre les deux, le test fonctionnel est l'activité principale – il représente environ 80 % des coûts –, complété par des tests non fonctionnels (par exemple, des tests de sécurité, de performance et désormais aussi d'expérience utilisateur). Le test SAP diffère du test d'applications individuelles. Si les concepts de base restent les mêmes, les outils sont généralement différents : SAP a désormais adopté Tricentis comme norme. De plus, les tests SAP mettent davantage l'accent sur les tests d'intégration et le flux de données entre les applications. Les données (c'est-à-dire l'échange de données, les tableaux et les données de base) ont une priorité beaucoup plus élevée dans l'univers SAP que dans les applications développées individuellement.

Au cours des vingt dernières années, les tests fonctionnels sont restés largement inchangés et reposaient sur un processus fondamental : exigences ou récits d'utilisateurs, cas de test et scripts de test. De nombreuses tentatives ont été faites pour automatiser ce processus – vous souvenez-vous des „ frameworks de test sans script “ ? Avec l'avènement des méthodes agiles et des outils DevOps, de nouvelles plateformes ont vu le jour, qu'elles soient appelées DevOps ou Continuous Testing. Le secteur parlait d'hyperautomatisation. Néanmoins, le processus composé d'exigences, de cas de test et de scripts est resté central.

Gains de productivité considérables

Pourquoi cet aperçu historique des tests ? Les LLM vont révolutionner les tests. Si les récits utilisateurs sont relativement bien formulés, les LLM peuvent générer des scripts de test en quelques minutes, au lieu de plusieurs semaines. Les gains de productivité sont impressionnants et le coût des LLM est minime (et continue de baisser) par rapport à la main-d'œuvre humaine. La rédaction de scripts de test ne nécessite plus d'ingénieurs de test, elle est automatisée. À l'avenir, les tests fonctionnels ne constitueront donc plus un goulot d'étranglement dans les projets SAP.

Une révolution est en cours, dont les effets seront considérables dans les années à venir : elle va transformer l'écosystème des outils, rendre superflues les licences et les abonnements logiciels et réduire considérablement les efforts de test. Les LLM sont parfaitement adaptés aux projets Greenfield, Grow ou Public Cloud. La nature même de SAP, avec sa dépendance à l'égard de processus métier standardisés, le rend idéal pour ce type de projets dans le cadre de tests fonctionnels. Les processus métier SAP standardisés sont bien documentés et facilement accessibles, et peuvent être utilisés pour créer des artefacts de test.

L'utilisation des LLM dans les environnements brownfield (et bluefield) – qui, on peut le dire à juste titre, représentent la majorité des projets S/4 – s'avère plus difficile. Du point de vue des tests, la priorité n'est plus ici de créer de nouveaux artefacts de test à partir de zéro, mais de comprendre les stocks de tests existants.

La plupart des organisations (les chiffres sont difficiles à établir) disposent de plusieurs milliers d'artefacts de test (également difficiles à quantifier), notamment des exigences, des scénarios de test, des cas de test et des scripts. Ces artefacts constituent à la fois un atout (ils reflètent les processus métier de l'organisation au niveau des transactions SAP) et un fardeau.

La prochaine étape consiste donc à comprendre ces artefacts : leur fonction, leur qualité et leur pertinence. Ce n'est pas la première fois que des organisations examinent leurs stocks de tests. La dernière tentative, il y a quelques années, utilisait le NLP pour identifier les cas de test redondants. Cette fois-ci, cependant, les LLM offrent des capacités de rétro-ingénierie : ils peuvent générer des cas de test à partir de scripts de test ou d'histoires d'utilisateurs. En d'autres termes, les LLM peuvent aider à déterminer quels scripts de test doivent réellement être exécutés, afin que les organisations puissent se concentrer sur l'essentiel, plutôt que de traiter l'ensemble de leur stock de tests.

Réduire les coûts, mais où ?

Il s'agit là de la première étape dans l'utilisation des LLM dans l'ingénierie de la qualité. Le monde des LLM est un monde plein d'opportunités, mais aussi plein de défis. Les LLM apportent certes d'énormes gains de productivité, mais ceux-ci ne se traduisent pas nécessairement par des économies significatives. Cela doit encore être mieux compris. Nous avons toutefois quelques indications : les tests sont un processus comportant de nombreuses étapes, au-delà des tests fonctionnels, et comportant des goulots d'étranglement (par exemple, la disponibilité des environnements de test) qui peuvent affecter la durée totale du cycle de test.

Un autre aspect concerne la manière dont les experts en tests utiliseront les LLM. Vont-ils exploiter les gains de productivité pour raccourcir les cycles de test ? Ou vont-ils consacrer une partie du temps gagné à des contrôles qualité supplémentaires et à des analyses des causes afin d'améliorer la qualité des logiciels ? Ce serait une évolution formidable, car les tests logiciels et la qualité des logiciels n'ont jamais été aussi étroitement liés qu'aujourd'hui.

Continuer vers l'inscription du partenaire :